Fix mouse drags, and stop warning about a secure context that exists - #4
Merged
Conversation
An <img> is natively draggable, so a press-and-move on a desktop started an HTML5 drag-and-drop, which fires pointercancel and springs the image back a few pixels into the gesture. Every swipe on a desktop was dead, and touch was unaffected — a native drag never starts from a touch — which is why it went unnoticed on the platform this was written for. Both the attribute and the -webkit- property: Safari has long wanted the property as well. There is no unprefixed form; it is not a standard property. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa
The note was printed whenever TLS was off, including on a loopback bind — where localhost *is* a secure context, Wake Lock and Fullscreen both work, and the note advised a certificate for a problem the deployment did not have. Everything uncertain still warns. A bare port is every interface, a hostname other than localhost can resolve anywhere, and an unparseable address is about to fail at Listen regardless. A redundant note costs a line of log; a missing one sends someone hunting for why the screen keeps sleeping. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa
Two invariants that look like tidiness and are not: draggable="false" is the only reason a desktop swipe works at all, and keyOutcome/swipeOutcome share a vocabulary on purpose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent small fixes, both found while running the app locally.
Mouse drags never worked
An
<img>is natively draggable, so a press-and-move on a desktop started an HTML5 drag-and-drop, which firespointercancel— the image springs back a few pixels into the gesture and no swipe ever resolves.draggable="false"on#photo, plus-webkit-user-drag: nonebecause Safari has long wanted the property as well as the attribute.Touch never starts a native drag, which is why this was invisible on the platform the app was written for.
The secure-context note fired on loopback
main.goprinted "reached by LAN IP over http, the screen will sleep and fullscreen is unavailable" whenever TLS was off — including on127.0.0.1:6969, wherelocalhostis a secure context and both features work. It advised a certificate for a problem the deployment did not have.loopbackOnlyanswers false for everything uncertain: a bare port is every interface, a hostname other thanlocalhostcan resolve anywhere, an unparseable address is about to fail atListenanyway. A redundant note costs a line of log; a missing one sends someone hunting for why the screen keeps sleeping.main_test.gocovers the table, including127.0.0.2and[::1].Verified
Both against a running server, not just read:
and the rebuilt binary serves
draggable="false"and-webkit-user-dragfrom the embedded assets. The drag behaviour itself still wants a human with a mouse — there's no browser automation on this machine.🤖 Generated with Claude Code
https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa